Unchecked capture_exception call

_maybe_capture_error() assumes the provided posthog object has a capture_exception method. With capture_errors=True, passing a PostHog client version (or a stub) that lacks capture_exception will raise AttributeError, which then gets swallowed by the broad except Exception, meaning errors silently won’t be reported (and it’s hard to diagnose). Consider guarding the call (e.g., hasattr(self._client, "capture_exception")) and/or logging at least once at WARNING when the method is missing so users know why capture isn’t happening.

This is a comment left during a code review.
Path: posthog/ai/prompts.py
Line: 97:99

Comment:
**Unchecked capture_exception call**

`_maybe_capture_error()` assumes the provided `posthog` object has a `capture_exception` method. With `capture_errors=True`, passing a PostHog client version (or a stub) that lacks `capture_exception` will raise `AttributeError`, which then gets swallowed by the broad `except Exception`, meaning errors silently won’t be reported (and it’s hard to diagnose). Consider guarding the call (e.g., `hasattr(self._client, "capture_exception")`) and/or logging at least once at WARNING when the method is missing so users know why capture isn’t happening.

How can I resolve this? If you propose a fix, please make it concise.

Tests are not parameterized

The new TestPromptsCaptureErrors cases are all the same shape (setup fetch failure/success → call get() → assert on capture_exception). This increases repetition and makes it easier to miss scenarios when adding new branches. The repo preference is parameterized tests; these can be collapsed into a single parameterized test that covers (fallback vs stale cache vs re-raise vs success) and toggles (capture_errors on/off, client present/absent).

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

This is a comment left during a code review.
Path: posthog/test/ai/test_prompts.py
Line: 512:516

Comment:
**Tests are not parameterized**

The new `TestPromptsCaptureErrors` cases are all the same shape (setup fetch failure/success → call `get()` → assert on `capture_exception`). This increases repetition and makes it easier to miss scenarios when adding new branches. The repo preference is parameterized tests; these can be collapsed into a single parameterized test that covers (fallback vs stale cache vs re-raise vs success) and toggles (`capture_errors` on/off, client present/absent).

<sub>Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!</sub>

How can I resolve this? If you propose a fix, please make it concise.

you dont need to do this

https://github.com/PostHog/posthog-python/blob/main/RELEASING.md

so we are reporting our own errors?
what's the final user gonna do with this when those errors are in their error tracking tab?

Good question — I think the framing is actually from the user's perspective, not ours. The errors surfaced here aren't "PostHog internals" — they're 404s (prompt typo / deleted), 403s (key perms), auth failures, and network errors. All actionable by the app developer. If my app's prompts were silently falling back for two weeks and PostHog didn't surface it, I'd be pretty upset. It's opt-in (capture_errors=False by default), runs before the fallback chain so visibility doesn't cost reliability, and swallows capture-side failures so it can't break the caller. WDYT?

mmm I see, then yeah for a few errors that do make sense eg 404, 403 etc but not everything
eg network errors, timeouts, etc, this would be just noisy, affecting the noise x ratio error tracking quality cus those errors specifically arent actionable
can we at least filter only to capture the errors that are actually actionable? (this will depend on the API contract - http errors)

Hmm if PostHog is down and my latest prompts aren't getting to my app you are saying to not error track that in my PostHog as a user? Do errors have to be actionable? Is that some sort of thing that users are aware or when using error tracking or something?

I'm not super up on error tracking fully tbh but feel a bit uncomfortable making such decisions here on behalf of future users (unless this kinda just is the norm or way error tracking works on posthog? Eg "actionable error tracking" where we do sort of try curate on your behalf, that's a bit different then).

Opt in too here as a gate helps maybe.

The noise problem then is something you manage in error tracking itself via the groupings and rules and AI no?

Or maybe there is some way to make the different error types configurable and use like a sane default more like what you say perhaps.

Although if my prod app was not getting latest prompts and error tracking was not surfacing that and it turned out PostHog prompts was just down and we missed it for a bit say, and then I found this thread where we decided to just not surface it. I'd be very mad.

Or am I being a bit stubborn here? Like I think of an error as an error, but of course it's always more nuanced where you draw the line so maybe that's the point here perhaps of where that is.

I don't disagree with most of your comments, but if posthog is down, or your internet is down, there's not much you can do besides having a fallback on the client
also, capturing errors most likely wont go thru anyway since most likely that endpoint is also down, or you are shooting the server with more requests and causing even more problems
Error tracking should focus on actionable errors I can address on my end.
I wouldn't want to pay for error events that the only solution is "tell PostHog to be more reliable or tell me to have a more stable internet", but I am very opinionated about this, I know
The way I see this is more about "SDK diagnostics", we failed to request the prompts, and that's an SDK issue and not a customer issue.
I'm not familiar with this product, so I'll approve it and leave it with you. I just wanted to share my 2 cents

Yeah I know what you mean, I'm kinda thinking of the potential code in here to cherry pick errors as an implicit suppression rule in PostHog error tracking.

Going to research a bit more on how it all works and what other parts of the SDK already do for stuff like this just to make sure I'm at least in line with them and things like that.

Eg does PostHog error tracking itself then maybe need some sort of new template for these new potential prompt errors etc.

Will check all that before merging to be sure.

awesome, thx